This invention relates to authentication of a user.
Many modern systems require a user to provide credentials in order to gain access to services. Conventionally the user provides a user name and a password to the service provider, and the service provider checks those details against a log-on database in order to verify that they match the credentials of a valid user identity. The user can then be granted rights in accordance with the identity they have demonstrated. It would be insecure for a user to have the same credentials for all service providers, so each user must remember numerous combinations of log-on credentials. If the user tries to remember all their passwords they are at risk of forgetting them, which will mean that they cannot have access to the service until the service-provider has provided them with replacement credentials. The alternative to memorising the credentials is to write them down or store them electronically, but that might give third parties access to them.
To address these problems a number of schemes that use centralised authentication have been devised.
OpenID offers two modes of operation: dumb mode and smart mode. Dumb mode can only provide an outcome of “true” or “false” from the authentication process, so it is anticipated that in most cases smart mode will be used. OpenID smart mode is illustrated in FIG. 1. The communication sequence starts with the user (UA) requesting a web page served by a web site (more generally a relying party/service provider: RP/SP) using OpenId authentication. The user will be prompted to enter their username. Based on the username the web site establishes which entity acts as identity provider (IDP) for that user. The RP/SP contacts the IDP and exchanges with the IDP key information which will be used to encrypt and decrypt the token that the IDP returns to indicate the outcome of the identification process. Once the IDP and the RP/SP have exchanged key information, the user's web browser is redirected to the IDP's web site by means of an HTTP 302 command. Once that the user's browser has been redirected to the IDP the user enters their authentication credentials, the IDP determines whether those credentials match those of a valid user identity and composes a response that indicates the outcome of that determination. That response is encrypted using the key that was previously exchanged. The user's browser is then redirected back to the web site of the RP/SP by means of an HTTP 302 command. The encrypted authentication outcome is carried within the redirection parameters, so it can be detected by the RP/SP. At the RP/SP the authentication outcome is decrypted, so the RP/SP can find whether the user is authenticated, and as which user identity. The RP/SP then provides a web response to the user based on the authentication outcome.
One problem with OpenId authentication is that different IDPs may provide different qualities of authentication. The authentication process is not standardised in OpenID. Also, in Open ID trust between the user, the RP/SP and the IDP is implied, rather than being enforced by means such as SSL. If that trust is not well placed, the frequent HTTP redirects represent potential security weak points in the process. The OpenId trust model is only implied, there is not enforcement, without the use of additional trust enforcement such as SSL, OpenId is therefore vulnerable.
Another form of devolved authentication is Microsoft's Cardspace. FIG. 2 shows the communication sequence for authentication using Cardspace. One disadvantage or limitation of Cardspace is that it needs an advanced Cardspace client which manages the (locally stored) information cards available to the user. This means that Cardspace-based authentication can usually be carried out only with a user's own PC, which prevents its use when the user is using a foreign PC, e.g. at an Internet café. A further limitation of the Cardspace client is the dependency on a secured Microsoft Windows operating system, which is not always available to a user. Home users of Microsoft Windows do not always secure their installations by enabling password protection etc. Cardspace is not platform independent, it only runs on Microsoft Windows and many users do not use Microsoft Windows.
The Liberty Alliance's Identity Federation Framework (ID-FF) offers another form of devolved authentication. In the ID-FF system the user has four ways of performing authentication.    1. Authentication may be initiated by the user navigating to the website of the RP/SP. The authentication may then proceed in:            a. Advanced client mode, which operates similarly to Cardspace.        b. Native browser functionality mode, which operates similarly to OpenID.            2. Authentication may be initiated by the user navigating to the IDP. The authentication may then proceed in:            a. Advanced client mode, in which the identity exchange process uses a profile based on SOAP and HTTP. A typical web browser is not able to process SOAP-based web service method calls, so this has the disadvantage that it calls for the user to have some form of advanced client. Also, in this scenario the user has navigated first to the IDP. The mechanism by which the user will consume the services of an RP/SP using any identity assertion he gets from the RP/SP is not clear.        b. Native browser functionality mode. As with the OpenID process, this makes use of HTTP redirect commands, which represents a potential security risk.        
There is therefore a need for an improved mechanism for authentication.
According to one aspect of the present invention there is provided a method of authenticating a user to a service provider by means of an authentication provision unit, the method comprising: in a first stage of the method: a. receiving credentials from a user; b. determining whether the credentials received from the user represent a valid logon; and c. if that determination is positive: i. generating at least one network address comprising a domain address and at least one instance parameter, the instance parameter uniquely identifying the user and the instance of generation of the network address; and ii. providing the network address to the user; and in a second stage of the method: a. receiving a parameter from a service provider; b. determining whether the received parameter indicates a valid attempt to log on to the service provider by checking that the received parameter matches an instance parameter that has previously been issued to a user and that has not previously been received from a service provider; and c. if that determination is positive: signalling to the service provider over a secure channel a message indicating that the received parameter represents a valid logon attempt, the message including credentials of the user to whom the instance parameter that matches the received parameter had been issued.
In the step of providing the network address to the user, the network address may be provided to the user over a secure channel. That may be an encrypted channel.
The secure channel over which the message is signalled to the service provider may be an encrypted channel.
The network address may be provided to the user in the form of a web page having a link to the network address. The instance parameter may be an HTTP querystring parameter to the network address.
The step of determining whether the received parameter indicates a valid attempt to log on to the service provider may comprise checking that user to whom the instance parameter that matches the received parameter had been issued has not logged off from the authentication provision unit since the instance parameter was issued.
The step of determining whether the received parameter indicates a valid attempt to log on to the service provider may comprise checking that the instance parameter that matches the received parameter was issued to a user as part of a network address that included a domain address corresponding to the service provider.
The method may comprise, if the determination in the first stage of the method is positive: i. generating a plurality of network addresses, each network address comprising a domain address and at least one instance parameter, the instance parameter uniquely identifying the user and the instance of generation of the network address; and ii. providing the network addresses to the user.
The network addresses may be provided to the user in the form of iconised links to the network addresses.
The instance parameter may identify the time at which it was generated. The step of determining whether the received parameter indicates a valid attempt to log on to the service provider may comprise checking that the difference between the time at which the instance parameter that matches the received parameter was generated and the current time is less than a predetermined value.
The method may comprise the steps subsequent to step c.ii of the first stage of automatically generating at least one replacement network address comprising the domain address and at least one replacement instance parameter, the replacement instance parameter uniquely identifying the user and the instance of generation of the network address; and providing the replacement network address to the user and subsequently treating the replacement instance parameter as the instance parameter in the second stage of the method.
According to a second aspect of the present invention there is provided an authentication provision unit for authenticating a user to a service provider, the authentication unit being configured to: in a first stage of the authentication process: a. receive credentials from a user; b. determine whether the credentials received from the user represent a valid logon; and c. if that determination is positive: i. generate at least one network address comprising a domain address and at least one instance parameter, the instance parameter uniquely identifying the user and the instance of generation of the network address; and ii. provide the network address to the user; and in a second stage of the authentication process: a. receive a parameter from a service provider; b. determine whether the received parameter indicates a valid attempt to log on to the service provider by checking that the received parameter matches an instance parameter that has previously been issued to a user and that has not previously been received from a service provider; and c. if that determination is positive: signal to the service provider over a secure channel a message indicating that the received parameter represents a valid logon attempt, the message including credentials of the user to whom the instance parameter that matches the received parameter had been issued.